An integration of Z and Timed CSP for specifying real time embedded systems

to Concrete The transition between abstract and concrete specification units is not really a refinement step. Rather, a concrete specification unit is constructed from scratch in order to define a model that meets the requirements defined by an abstract specification unit; demonstrating the satisfaction of these requirements is a verification task. Verification techniques for RT-Z are part of future work, see Chapter 13. We nevertheless define the implementation relation between abstract and concrete specification units in this section. Definition 10.2 An abstract specification unitASU is refined by a concrete specification unit CSU if, and only if, all external interactions consistent with CSU are also consistent with ASU—taking into 10.1. Refining Single Specification Units 157 account the potential change of data representation as recorded in the INTERFACE section of RSU. ASU vRSU TF CSU ⇔ timed failuresC [[CSU ]] ⊆ RetrInterface(|{RSU}|)(|timed failuresA [[ASU ]] |) Note that we have not defined a refinement relation between pairs of abstract specification units. From our point of view, abstract specification units are not subject to refinement, because they fix mere requirements, which should be already known when the part of the development process starts that is supported by RT-Z. 10.1.4 Open System View Considering a specification unit in the open system view, we are interested in both its interaction at the external interface and the evolution of its internal data state. To check if there is a refinement relationship between two specification units, we must compare their associated sets of timed failures and timed states. Again, the timed failures and timed states of the two units cannot be compared directly because of a potential change of data representation. The comparison is thus made with respect to the retrieve relations defined in Section 10.1.2. The following definitions are analogous to that of the closed system view. Concrete to Concrete Definition 10.3 A concrete specification unit CSUA is refined by a concrete specification unit CSUC with respect to a retrieve specification unit RSU if, and only if, all external interactions and data state evolutions consistent with CSUC are also consistent with CSUA—taking into account the potential changes in data representation as recorded in the INTERFACE and STATE sections of RSU. CSUA vRSU TFTS CSUC ⇔ timed failures statesC [[CSUC ]] ⊆ RetrInterface/State(|{RSU}|)(|timed failures statesC [[CSUA ]] |) Abstract to Concreteto Concrete Definition 10.4 An abstract specification unit ASU is refined by a concrete specification unit CSU with respect to a retrieve specification unit RSU if, and only if, all external interactions and data state evolutions consistent with CSU are also consistent with ASU—taking into account the potential changes in data representation as recorded in the INTERFACE and STATE sections of RSU. 158 Chapter 10. Refinement ASU vRSU TFTS CSU ⇔ timed failures statesC [[CSU ]] ⊆ RetrInterface/State(|{RSU}|)(|timed failures statesA [[ASU ]] |) 10.1.5 Techniques for Establishing Refinement According to the discussion in the previous two sections, the task that remains to be dealt with is the refinement of concrete specification units. In this context, our aim is to make use of the existing refinement techniques of the base formalisms Z and timed CSP. Because of the chosen approach to defining the meaning of concrete specification units—the parallel composition of the Z and CSP part—their parts can be refined independently of each other. This independence is ensured by the monotonicity of the parallel composition operator with respect to refinement in the timed failures model. Concerning the CSP part of concrete specification units this means that we can simply use the refinement techniques provided by timed CSP. Concerning the Z part, on the other hand, we must establish a link between the refinement techniques provided by Z and refinement in the timed failures model. In other words, we must establish that using state-based techniques to refine the Z part results in a refinement of the timed CSP interpretation of the Z part according to our semantic definitions in Chapter 9. This approach follows the work of Josephs [1988] who has demonstrated that state-based refinement techniques are consistent with refinement in the failures–divergences model of (untimed) CSP. We cannot, however, simply adopt his results in the context of RT-Z, because • our approach to defining the timed CSP semantics of a Z specification differs from his approach to defining the CSP semantics of a state-based system and • two different semantic models are involved: the timed failures model and the failures– divergences model. We proceed as follows. We first introduce the definition of the notions of forward and backward simulations. In Section 10.3 we prove that forward and backward simulations imply refinement in the timed failures/states model of RT-Z. Josephs [1988, Rules 2.2 and 2.3 on p. 12] has defined the notions of downward and upward simulations in the context of state-transition systems.3 Wemust translate his definitions into the context of Z as used within RT-Z. The most essential aspect of this translation is the identification of the set next(σ), denoting the set of outgoing actions from the state σ, and the set of operations whose preconditions are satisfied in the data state corresponding to σ. This identification corresponds to the rôle we have assigned to operation preconditions in RT-Z: an operation is blocked in a data state in which its precondition is not satisfied. The most substantial difference between the following conditions characterising forward and backward simulations in RT-Z and the corresponding conditions given in [Josephs, 1988] is that we cannot (explicitly) quantify over the set of operation identifiers present in a specification unit, whereas Josephs has used universal and existential quantifiers over the set of actions 3 Instead of the terms upward and downward simulation, we use the terms forward and backward simulation, because they are more intuitive and also used in [Woodcock and Davies, 1996]. 10.1. Refining Single Specification Units 159 of a state-transition system. Another difference between the definitions of Josephs (and also the definitions of forward and backward simulation in [Woodcock and Davies, 1996]) and our definitions is that we have taken into account the refinement of data types associated with the input and output parameters of operations. The conditions have been extended accordingly. Forward Simulations. Let CSUA and CSUC be two concrete specification units. Let RSU be a retrieve specification unit defining the various retrieve relations. The schema RSU.RetrState is called a forward simulation between the data states of CSUA and CSUC if the following three conditions hold for each operation schema OP. All conditions are implicitly universally quantified over the set of operation identifiers defined in CSUA and CSUC. The conditions are a translation of the Conditions 1–3 of Rule 2.2 of [Josephs, 1988].